Test Coverage With Codecov
Codecov test coverage
I utilise Test-Driven Development when writing software in order to mitigate against misuse cases.
All jokes to the side, ensuring that your functions are safe is vital. This helps mitigate against poor documentation and misinterpretation.
Code coverage gives an indication of the percentage of code lines that are exercised when the test battery is run. However, I would advise caution in assuming that a high coverage equates to quality software. It tends to be very easy to write a suite of tests that result in high coverage. This does not mean that all necessary exception handling has been considered and tested.
Thorough and well-considered test conditions are excellent tools in assuring quality software. It also means that you can turn your failures into future successes - every bug you encounter can be converted to a meaningful test.
Below, you can view the test coverage workflow on pushing to the remote.
As this package involves some file operations, writing to and reading from disk is required in order to test the functions. Writing to disk is not allowed by CRAN policies in any test, example or gist. In order to overcome this, a nuanced approach is required as the {testthat} approach executes testfiles within a temporary directory.
Then by creating and writing dependencies to tempfile(), execution of the tests can be underaken without the risk of any detritus being left behind on disk.
Linting
Automated linting using the {lintr} package with GitHub actions is used to help ensure code adheres to the tidyverse style guide. Code readability is important in assisting collaboration. Data Science Campus guidance is to apply the tidyverse style guide.
Perhaps more important than the adopted style is to ensure that code is conscientiously commented. Your colleagues and future self will value the effort taken in explaining your code.
